home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-82 < prev    next >
Text File  |  1988-12-01  |  9KB  |  256 lines
  1.  
  2.  
  3.  
  4.           M.I.T. Lab. for Computer Science Network Implementation Note No. 5
  5.  
  6.                                                           February 15, 1979
  7. IEN-82
  8.  
  9.  
  10.  
  11.                                LCS Net Address Format
  12.  
  13.                                     Noel Chiappa
  14.                                      David Clark
  15.                                      David Reed
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.           This note defines the current format  of  addresses  in  the  LCS
  24.           Local Net and their translation into LCS hardware headers as well
  25.           as InterNet addresses and CHAOS Net addresses.
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.           _________________________________________________________________
  55.           This  note  is an informal working paper of the M.I.T. Laboratory
  56.           for Computer Science.  It should not be  reproduced  without  the
  57.           author's  permission,  and  it  should  not  be  cited  in  other
  58.           publications.
  59.                                   February 15, 1979
  60.  
  61.  
  62.                This note defines the current format of addresses in the LCS
  63.           Local Net and their translation into LCSNet hardware  headers  as
  64.           well  as  CHAOS  addresses  and  InterNet  addresses. Address and
  65.           protocol numbers specific  to  the  LCSNet  are  also  temporaily
  66.           defined in this note.
  67.  
  68.  
  69.                Note  that  the proposal stated in this is not final, but is
  70.           motivated by other considerations. The LNI as currently  designed
  71.           contains sophisticated name matching facilities of unknown worth.
  72.           It  is  not yet clear whether this hardware is useful or not, but
  73.           we felt that we should at least explore  the  possibilities,  and
  74.           have  thus designed the protocol to take maximum advantage of the
  75.           hardware's features. Depending on the results of our  preliminary
  76.           work  with the name matching hardware, we may or may not keep< it
  77.           in future versions of the LNI.
  78.  
  79.  
  80.                The basic hardware format of a LCS-LN packet is as follows:
  81.  
  82.  
  83.           DPNM    31                               0
  84.                   |________________________________|
  85.  
  86.           DPN     31                               0
  87.                   |________________________________|
  88.  
  89.           OPN     31                               0
  90.                   |________________________________|
  91.  
  92.           LEN     15               0
  93.                   |________________|
  94.  
  95.           DATA    8n-1             0
  96.                   |________________|
  97.  
  98.  
  99.  
  100.                (Unless others stated, all bit numbers are  in  decimal  and
  101.           all others are in octal.)
  102.  
  103.  
  104.                The  DPNM,  DPN,  OPN  and LEN fields are all defined by the
  105.           hardware. The DATA field contains LEN bytes  of  data.  The  DPNM
  106.           (Destination   Process   Name   Mask)   together   with  the  DPN
  107.           (Destination Process Name) specify the destination  address,  and
  108.           the OPN (Originating  Process Name) is the sender's address. This
  109.           field  is  actually  unused  by the hardware, but is reserved for
  110.           future use.  The workings of the DPNM and DPN are as follows:  in
  111.           every  LNI  there is an array of sofware loadable names (the Name
  112.           Table, NT), each with  a  DPNM  and  a  DPN.  The  name  matching
  113.           algorithm is a follows: for each bit in the name, if the two bits
  114.           in  the  DPN's  are  equivalent or if either DPNM bit is on, then
  115.                                   February 15, 1979
  116.  
  117.  
  118.           that bit matched. If all the bits matched, then the name matched.
  119.  
  120.  
  121.                The basic format of the headers (imposed by the sotware)  is
  122.           as follows:
  123.  
  124.  
  125.           DPNM    31 Type  23                       0
  126.                   |________|________________________|
  127.  
  128.           DPN     31  Rsd  23                       0
  129.                   |________|________________________|
  130.  
  131.           OPN     31           Reserved            0
  132.                   |________________________________|
  133.  
  134.           LEN     15               0
  135.                   |________________|
  136.  
  137.           DATA    8n-1             0
  138.                   |________________|
  139.  
  140.  
  141.           "Rsd"  stands  for  "Reserved" and "Type" is the Local Type. As a
  142.           general rule the value of 0 for any field is reserved for  fixing
  143.           catastrophes   not   yet   visible  to  the  eye.  The  following
  144.           conventions are to be used in assigning  type  numbers:  types  1
  145.           through  077 have a common address format, specified below, types
  146.           100 through 277 are reserved,  and  types  301  through  377  are
  147.           available  for (experimental) protocols which may use the next 24
  148.           bits of address as they see fit.
  149.  
  150.  
  151.                The intention of the above is that bridges be able to easily
  152.           recognize, via the top bit(s) whether or not  the  address  field
  153.           fits  a  common format. Clearly there are enormous advantages, in
  154.           the building of bridges and other areas, where it is desirable to
  155.           have a common address format, but it is obviously also  desirable
  156.           not   to  hamstring  the  development  of  other  very  different
  157.           protocols (such as a distributed process system or a  distributed
  158.           file system) which would fit poorly into the classical addressing
  159.           system.
  160.  
  161.  
  162.                For  types  that  use the common address format, the address
  163.           format is:
  164.  
  165.  
  166.                    00  Type    SNet      Rsd     Host
  167.                   31 29     23       15       7        0
  168.                   |__|______|________|________|________|
  169.                                   February 15, 1979
  170.  
  171.  
  172.           The field marked "Rsd" is reserved for future use. It is intended
  173.           that it be used for address expansion should it become necessary,
  174.           but it may be used for whatever appears  appropiate,  such  as  a
  175.           "Flag" field.
  176.  
  177.  
  178.                SubNet  numbers  and Host Numbers (per SubNet) are currently
  179.           being assigned in common with  the  AI  Lab's  CHAOS  Net  in  an
  180.           attempt  to  maintain  an  MIT  wide  addressing  unity. The main
  181.           repository  for   these   numbers   is   in   the   online   file
  182.           AI:SYSENG;HOSTS > on MIT-AI.  numbers specific to our net are:
  183.  
  184.  
  185.           Number  SubNet
  186.  
  187.             0             Reserved
  188.             1-7           Unassigned
  189.             10            LCS LN
  190.             11-377        Unassigned
  191.  
  192.           Subnet 10
  193.           Number          Host
  194.  
  195.             0             Reserved
  196.             1 - 7         Unassigned
  197.            10             CSR 11/40
  198.            11             DSSR 11/70
  199.            12 - 17        Unassigned
  200.            20             VAX
  201.            21 - 377       Unassigned
  202.  
  203.  
  204.           It is not intended that this note be the official source for host
  205.           and  subnet  numbers;  rather,  there  will be an online database
  206.           which at the moment is the specified ITS file.
  207.  
  208.  
  209.                The assigned protocol types are:
  210.  
  211.  
  212.           Type            Use
  213.  
  214.             0             Reserved
  215.             1             InterNet Datagram (Internal)
  216.             2             CHAOS Packet
  217.             3-77          Unassigned
  218.             100-277       Reserved
  219.             300           Reserved
  220.             301           InterNet Datagram (Outbound)
  221.             302-377       Unassigned
  222.                                   February 15, 1979
  223.  
  224.  
  225.                In all cases the specified header is followed immediately by
  226.           a packet of the specified type  as  defined  in  the  appropriate
  227.           reference.  [1,2]  At the moment, the format of outbound InterNet
  228.           packets is as follows:
  229.  
  230.  
  231.                    11   000         Rsd       Ext Net
  232.                   31 29     23               7        0
  233.                   |__|______|________________|________|
  234.  
  235.  
  236.           where "Ext Net" is the major net number of the  destination.   In
  237.           internal  InterNet  packets, the mapping from InterNet Headers to
  238.           MIT addresses is simple; the 24  bits  of  "Address"  after  "Net
  239.           Number"  in  the  InterNet  header  have  the  same format as the
  240.           adddress of a  common  address  format  packet,  and  are  copied
  241.           directly into the header. In the future, some attempt may be made
  242.           to support variable address format addresses on inbound packets.
  243.                                   February 15, 1979
  244.  
  245.  
  246.                                      References
  247.  
  248.  
  249.           [1]  Postel,  Jonathan  B., "InterNetwork Protocol Specification,
  250.           Version  IV,"  Information  Sciences  Institute,  University   of
  251.           Southern California, IEN 54, September 1978.
  252.  
  253.           [2]  Greenblatt,  Richard  G.,  and  Moon, David, "CHAOS Protocol
  254.           Specification," Artificial Intelligence Laboratory, M.I.T., 1978.
  255. 
  256.